home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / dskut / combi113.zip / COMBI.FAQ < prev    next >
Text File  |  1993-05-03  |  10KB  |  202 lines
  1.  
  2.     This file contains some frequently asked questions about COMBI
  3.     and the answers.
  4.  
  5.  
  6.  
  7. Q: My system hangs during (or after) boot or when I start a certain program.
  8.    What should I do?
  9.  
  10. A: You may try the following steps:
  11.  
  12.     1. Disable usage of HMA by COMBI (remove '/H' installation switch).
  13.  
  14.     2. Turn off write caching (remove 'B' from cache options).
  15.  
  16.     3. Disable cache at all (add 'O' to cache options). You may turn
  17.        the cache on after successful boot if You see that COMBI does not
  18.        attempt to use memory that is not available (run MEM or other
  19.        program that can report of memory used by TSRs and device
  20.        drivers).
  21.  
  22.     4. Try loading COMBI into low memory (if it is loaded high).
  23.        Sometimes there is not enough upper memory for other programs
  24.        or device drivers that are loaded after COMBI. COMBI detects
  25.        amount of available memory under MS-DOS 5.0+ but not under other
  26.        DOS versions. In any case COMBI reports how much memory it uses
  27.        so You can decide which region of UMB memory is most appropriate
  28.        for it.
  29.  
  30.     5. Try to change the order of COMBI and other device drivers. Only
  31.        memory managers and disk managers require to be loaded before
  32.        COMBI.
  33.  
  34.     6. Try to find out which program conflicts with COMBI and whether
  35.        it is possible to reconfigure it to solve the problem.
  36.  
  37.     7. Send me e-mail with the results. I'll try to suggest a better
  38.        solution or fix the bug in COMBI (if it is COMBI's bug).
  39.  
  40.  
  41. Q: Is it possible to disable caching of some DOS partitions or network
  42.    drives?
  43.  
  44. A: No. Once installed COMBI caches all physical hard drives regardless
  45.    of the types of partitions on them (DOS partitions, disk manager
  46.    partitions, compressed partitions, non-DOS partitions) and never
  47.    caches network drives or RAM disks. This is not a waste of memory or
  48.    processor resources - if a partition (or some region on the hard disk)
  49.    is not accessed via BIOS INT 13h then COMBI does not cache it.
  50.  
  51.  
  52. Q: My Stacker (or SuperStor) manual recommends not to cache the compressed
  53.    drives. How to do that with COMBI?
  54.  
  55. A: It is recommended not to cache the logical partition created by Stacker
  56.    (SuperStor) but not the physical hard disk on which the compressed data
  57.    is stored. COMBI's cache speeds up Stacker's (SuperStor's) access to
  58.    compressed data rather than DOS's access to already uncompressed by
  59.    Stacker (SuperStor) data. So, caching is useful and compatible.
  60.  
  61.  
  62. Q: What is the optimal size of the cache buffer?
  63.  
  64. A: Probably, the larger is the cache buffer the better. It does not take much
  65.    longer to find a block in the large cache or to discover that it is not
  66.    present. If a certain application program that You run few times completely
  67.    fits into the cache with all the data it needs, then it is started much
  68.    faster.
  69.  
  70.  
  71. Q: How much memory does COMBI use?
  72.  
  73. A: This depends on installation parameters. You can estimate it the following
  74.    way. COMBI's resident code takes about 8 Kbytes, add the size of the
  75.    cache block (512 bytes times the block size - 'U:' parameter). The result
  76.    (about 12K for default block size) is the minimum contiguous memory block
  77.    COMBI may be installed in. The COMBI's data tables require 16 bytes per
  78.    cache block, so for 3 Mbytes buffer size (8 sectors per block) it takes
  79.    about 12K. The tables might be put into HMA ('/H' switch) if there is
  80.    enough HMA available (MS-DOS 5.0 leaves about 16K of HMA) or occupy
  81.    the space just after COMBI's code. If COMBI detects that there is not
  82.    enough memory for data tables immediately after its code (this is only
  83.    possible under MS-DOS 5.0 - other DOS versions do not provide this
  84.    information) then it attempts to allocate another memory block (which may
  85.    be in UMB or low memory).
  86.    For a system with 8 Mbytes of memory if COMBI uses 7 Mbytes it needs
  87.    about 40K. So, loading it into a small UMB block may be fatal.
  88.  
  89.  
  90. Q: How to flush the cache (force COMBI to write all the blocks that are
  91.    changed) from DOS or from a program?
  92.  
  93. A: The easiest way is not to do that at all - just wait a second then, if
  94.    there are dirty blocks in cache, update process is started (You can
  95.    see the hard disk LED twinkling) and when it is finished (the LED goes
  96.    off) all the blocks are written. There is the only case when that is not
  97.    true: if some sectors can't be written from 5th attempt COMBI does not
  98.    further try to write them, however, COMBI attempts to update other sectors
  99.    from the same block and/or other blocks.
  100.    Another way is to run 'COMBI f' to tell COMBI to flush cache. If there
  101.    are any errors the program will report that.
  102.    When You hit Ctrl-Alt-Del to reboot machine COMBI intercepts the last
  103.    key (Del) and forces writing. After the update is done Ctrl-Alt-Del
  104.    combination is passed to other programs that might need to perform some
  105.    shutdown actions.
  106.    If Your program needs to ensure that all blocks are updated to disk
  107.    it may issue INT 13h with AH=0, DL=80h (reset hard disks). I suppose that
  108.    is a common way supported by many other cache programs.
  109.  
  110.  
  111. Q: How to see the statistics of cache hits/misses?
  112.  
  113. A: Run 'COMBI' without any parameters. If the cache is on You'll see an
  114.    output like this:
  115.  
  116.     Statistics:
  117. RAM disk reads:      0/0
  118. RAM disk writes:     0/0
  119. Hard disk reads - requested:    731/4161  , passed to BIOS:   409/2728
  120. Hard disk writes - requested:    65/84    , passed to BIOS:    19/43
  121.  
  122.    In each pair of numbers 'NNNN/SSSS' the NNNN is the number of requests
  123.    to read/write and SSSS is the number of sectors requested.
  124.    For the example above about 44% ( (731-409)/731 ) of read requests were
  125.    satisfied without actual access to hard disk and about 34% of the requested
  126.    sectors were found in the cache. An average read request from DOS was
  127.    about 5.7 (4161/731) sectors per read. In fact, for such short reads the
  128.    seek for cylinder/sector takes most of the time, so the actual saving is
  129.    about 44% rather than 34%.
  130.    An average write request from DOS was 1.3 sectors while COMBI passed to
  131.    BIOS about 2.3 sectors per request. This means that some of requests
  132.    to write into adjacent sectors were grouped into a single request. And the
  133.    fact that only 51% (43/84) of sectors were actually written indicates that
  134.    DOS has been writing into the same sectors before they were actually
  135.    updated to disk (this is a common case for FAT and/or directory sectors).
  136.  
  137.    Your statistics may be quite different. For the example above (about
  138.    2 Mbytes read from disk) the 44% savings is a good result for the cache
  139.    of only 320K buffer size. As regards write statistics when large files
  140.    are written to disk the number of actual write requests may be larger
  141.    than DOS requested, since COMBI has to split long writes into shorter
  142.    (up to block size which is 8 sectors by default). However, this is not a
  143.    negative savings because the time while the hard disk seeks for the
  144.    requested sector is not idle but belongs to the process which is running.
  145.  
  146.  
  147. Q: How can I ensure that some XMS memory is actually loaned to a program?
  148.  
  149. A: If that program (like Windows or some editors) allows You to run a DOS
  150.    program (from DOS shell) You may try 'COMBI' without parameters. Another
  151.    part of the output may look like this:
  152.  
  153.     Current status:
  154. buffer size:    320K
  155. current size:   128K
  156. total number of blocks:     78 (8 sectors each)
  157. current number of blocks:   30 (0 - RAM disk, 30 - cache)
  158.  
  159.    Here 320K is the total size of XMS memory allocated to COMBI on
  160.    installation and 128K is the amount of memory it currently has at its
  161.    disposal. So, the rest 192K are loaned to other programs (for the example
  162.    above it was editor).
  163.  
  164.    Warning! When a program that used XMS memory terminates abnormally it
  165.    often does not free the allocated XMS. In this case COMBI is unable
  166.    to retrieve the whole buffer size back. If You have a utility which
  167.    may determine what XMS handles are allocated and free some of them
  168.    You may try to free the XMS handle that belonged to